PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.54

Text File | 1988-06-15 | 33.3 KB | 827 lines | [TEXT/ttxt]

24-May-88 01:51:24-PDT,34875;000000000000
Return-Path: <@RELAY.CS.NET:[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Tue, 24 May 88 01:50:44 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13277; 24 May 88 4:12 EDT
Received: from sdr.slb.com by RELAY.CS.NET id ai25854; 24 May 88 3:59 EDT
Date: Mon, 23 May 88 10:55 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #54
To: [e-mail]
X-VMS-To: in%"[e-mail]"

Date: Mon 25 Apr 88 11:05:32-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #54
To: Usenet-List: ;
Message-ID: <577965932.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>
ReSent-date: Mon 23 May 88 10:55:09-EDT
ReSent-from: Jeff Shulman <SHULMAN@SDR>
ReSent-to: [e-mail]

Usenet Mac Digest     Friday, April 22, 1988         Volume 4 : Issue 54

Today's Topics:
     Exciting questions on Macintosh SE !!!
     Fractals
     The Scores Virus
     Calling all Lisa owners/users ...
     info on expert-system shells sought
     AUX book
     Landscape printing
     MultiFinder switch bug with custom WDEFs
     Re: I fixed an unreadable floppy...now you can too !
     banner programs? (2 messages)
     PICT2 - bitmap compression
     Bug in MPW 2.0.2 Link tool
     Cursor only moves vertically.  Why? (2 messages)
     DataDesk Mac-101 Keyboard for the Mac Plus (non-ADB) and startup
     Kspool/hiding 'LaserWriter'
     Re: DataDesk Mac-101 Keyboard for the Mac Plus (non-ADB) and startup (2 messages)
     Re: Mac II ROM upgrade
     Re: MultiFinder switch bug with custom WDEFs

----------------------------------------------------------------------

From: [e-mail] (Newton Lee)
Subject: Exciting questions on Macintosh SE !!!
Date: 18 Apr 88 13:58:27 GMT
Organization: AT&T ISL Middletown NJ USA


Hi, does anyone know the answers to the following questions relating to
the Macintosh SE?

1. I want my program to reside in memory all the time while it launches
   other applications.  I tried placing my program into an INIT resource
   but the system blew up with error ID = 2.  Why?  Could it be the
problem
   of relocatable references created by the C compiler?

2. My program has to capture all keyboard and mouse events before they
   get to the other application.  One way to do this is to patch the
   system traps GetOSEvent and OSEventAvail.  Also, I have to install
   a JMP instruction in the system heap to jump to my program in the
   application heap.  Are there any better ways?  Are there any example
   source codes that do this?

3. I want my program to be able to read from some existing .snd
resources
   and play the sounds.  However, SndPlay (trap address 0xA805) doesn't
seem
   to exist in system 4.1 and I got a run-time error.  On the other
hand,
   I don't know how to use StartSound function to interpret .snd
resources.
   I couldn't find any book (except Inside Mac vol. 2 and 5) that talks
   about it.  Any ideas?

Thanks. Your help is greatly appreciated.

- Newton (mtund!newton 201/576-3541)


------------------------------

From: [e-mail] (David Shinberg)
Subject: Fractals
Date: 19 Apr 88 00:13:53 GMT
Organization: Union College, Schenectady, NY

I am starting a project that will entail displaying and generating
fractal  landscapes on a Mac II.  Has anyone done this yet?  I am
interested in both the Macintosh specific code and the general
algorithms so any code would be appreciated.  I have both Turbo and MPW
Pascal.  I also am familar enough with C to port C code.  This is for a
term project in Geometry.

Any Help will be greatly appreciated, even just a few good references
that have some algorithms explained.

                Thanks in Advance
                      Dave
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Disclaimer: Don't blame me ... I'm too new at this                          |
|                                                                             |
| David Shinberg               BITNET: 88_shinb@union                 |
| Box 2073                             UUCP: uunet!steinmetz!unioncs!shinberd |
| Union College                                                               |
| Schenectady NY, 12308                                                       |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


------------------------------

From: [e-mail] (Phil Draughon (ACNS))
Subject: The Scores Virus
Date: 18 Apr 88 16:11:09 GMT
Organization: Northwestern U, Evanston IL, USA


My colleague Bob Hablutzel got a copy of the Scores virus last Thursday
and disassembled it, and I've been studying and testing it ever since.
So far I've reverse-engineered about half the code and have a thorough
understanding of how it works.  This note is a preliminary report on
what I know so far, after four days of research.  It also outlines plans
for a disinfectant program.

The virus is definitely targeted against applications with signatures
VULT and ERIC.  I don't know if any applications with these signatures
exist or are planned to be released.

The virus infects your system folder when you run an infected program.

The virus lies dormant for two days after your system folder is first
infected.  After two, four, and seven days various parts wake up and
begin doing their dirty work.

Two days after the initial infection the virus begins to spread to other
applications.  I haven't completely finished figuring out this
mechanism, but it appears that only applications that are actually run
are candidates for infection.

After four days the second part of the virus wakes up.  It begins to
watch for the VULT and ERIC applications.  Whenever VULT or ERIC is run
it bombs after 25 minutes of use.  If you don't have a debugger
installed you'll get a system bomb with ID=12.  If you have MacsBug
installed you'll get a user break.

After seven days the third part of the virus wakes up.  Whenever VULT is
run the virus waits for 15 minutes, then causes any attempt to write a
disk file to bomb.  If you don't do any writes for another 10 minutes
the application will bomb anyway, as described in the previous
paragraph.  There's also more code to force a bomb after 45 minutes, but
I can't see any way that this code can be reached, given the forced bomb
after 25 minutes.

The virus identifies VULT and ERIC by checking to see if the application
contains any resources of type VULT or ERIC.  Applications with
signatures VULT and ERIC normally contain these resources, but other
applications normally don't.

I verified the behaviour of the virus by using ResEdit to add empty
resources of types VULT and ERIC to the TeachText application.
TeachText bombed as described above on an infected system, even though
TeachText itself was not infected!  While running my experiments I was
in ResEdit on the infected system and heard the disk whir.  Sure enough,
ResEdit was infected.  I've been running on an infected system with an
infected ResEdit for three days.  I reset the system clock to fool the
various parts of the virus into thinking it was time for them to wake
up.  The Finder has also become infected.  ResEdit, Finder, and the rest
of the system seem to be functioning normally.  Only my version of
TeachText modified to look like VULT or ERIC has been affected by the
virus.

If you repeat any of these experiments be very careful to isolate the
virus.  I'm using a separate dual floppy SE to perform my experiments,
and I've carefully labelled and isolated all the floppies I'm using.  My
main machine is an SE with a hard drive, where I have MPW and my other
tools installed.  It's OK to look at infected files on the main machine
(e.g. with ResEqual, DumpCode, etc.), but don't run any infected
applications on the main machine - that's how it installs itself and
spreads.  Children should not attempt this without adult supervision :-)

An infected application contains an extra CODE resource of size 7026,
numbered two higher than the previous highest numbered CODE resource.
Bytes 16-23 of CODE resource number 0 are changed to the following:

   0008 3F3C nnnn A9F0

where nnnn is the number of the new CODE resource.

You can repair an infected application by replacing bytes 16-23 of CODE
0 by bytes 2-9 of CODE nnnn, then deleting CODE nnnn.  I've tried this
using ResEdit on an infected version of itself, and it works. The MPW
utility ResEqual reports that the result is identical to the original
uninfected version.

The virus creates two new invisible files named Desktop (type INIT) and
Scores (type RDEV) in your system folder, and adds resources to the
files System, Note Pad File, and Scrapbook File.

Note Pad File and Scrapbook File are created if they don't already
exist.  Note Pad File is changed to type INIT, and Scrapbook File is
changed to type RDEV.  Both of these files normally have file type ZSYS.
 The icons for these two files change from the usual little Macintosh to
the generic plain document icon.  Checking your system folder for this
change is the easiest way to detect that you're infected.

Copies of the following five resources are created:

      Type     ID  Size  Files
     -----  ----- -----  -------------------------------------
      INIT      6   772  System, Note Pad File, Scrapbook File
      INIT     10  1020  System, Desktop, Scores
      INIT     17   480  System, Scrapbook File
      atpl    128  2410  System, Desktop, Scores
      DATA  -4001  7026  System, Desktop, Scores

A disinfectant program would have to repair all infected applications
and clean up the system folder, undoing the damage described above.  I
don't yet know exactly which files can be infected, but I know for sure
that Finder (file type FNDR) can get infected, and that applications
(file type APPL) can get infected.  For safest results the disinfectant
should examine and disinfect the resource forks of all the files on the
disk.  I recommend the following algorithm:

Scan the entire file hierarchy on the disk, and for each file on the
disk check it's resource fork.  Delete any and all resources whose type,
ID, and size match the table above.  Delete all files whose resorce
forks become empty after this operation.  If the resource fork's highest
numbered CODE resource is numbered two more than the next highest
numbered CODE resource, and if it's size is 7026, then patch the CODE 0
resource as described above, and delete the highest numbered CODE
resource.  Also examine all files named Note Pad File and Scrapbook
File.  If their file type is INIT or RDEV, change it to ZSYS.

I'm fairly confident that a disinfectant program implemented using the
algorithm above would sucessfully eradicate the virus from a disk,
restore all applications to their original uninfected state, and not
harm any non-viral software on the disk.  It should work even on disks
with multiple infected system folders.  I also believe that it should
work even if run on an infected system, and even if the disinfectant
program becomes infected itself!  There's a small chance that it could
delete too many resources, and hence damage some other application, but
that's a small price to pay for a clean system.

Getting rid of a virus is tricky, even with a disinfectant program.  The
disinfectant program should be placed on a floppy disk along with a
system folder.  Make a backup copy of this disk.  The machine should be
booted using the startup disk you just made, and then the disinfectant
should be run on all the hard drives and floppies in your collection,
including the backup copy of the startup disk you just made.  Don't run
any other programs or boot from any other disks while disinfecting - you
might get reinfected.  When you're all done, reboot from some other
(disinfected) disk and immediately erase the startup disk you used to do
the disinfecting, which may be (and probably is) infected itself.  This
should absolutely, positively get rid of all traces of the virus.  The
backup disk you made and disinfected should contain an uninfected copy
of the disinfectant program in case you need to use it again.

There are at least two red herrings in the virus.  It uses a resource of
type 'atpl', which is usually some sort of AppleTalk resource.  As far
as I can tell, however, the virus does not attempt to spread itself over
networks.  The 'atpl' resource is used for something else entirely.
This is not a bug.  Also, the virus creates the file Desktop in your
system folder.  This is done on purpose.  It is not a failed attempt to
modify the Finder's Desktop file in the root directory.  The file is
used by the virus, and has nothing to do with the Finder.

I don't know why the virus seems to cause reported problems with
MacDraw, printing, etc.  Perhaps it's a memory problem - the virus
permanently allocates 16,874 bytes of memory at system startup (four
blocks in the system heap of sizes 772, 40, 8, and 334, and one bock at
BufPtr of size 15360).  I've only found one possible bug in the virus
code, and it looks pretty harmless.  The code is very sophisticated,
however, and I can easily understand how I might have overlooked a bug,
or how it might interact in strange unintended ways with other
applications and parts of the system.

When we've finished completely cracking this virus we'll probably
distribute another report.  I've posted these preliminary results now to
get the information out as quickly as possible.  We also hope to write
the disinfectant program, if someone else doesn't write it first.

I've decided not to distribute detailed information on how this virus
works.  I'll distribute detailed technical information about what it
does and how to get rid of it, but not internal details.  This was a
very difficult decision to make, because normally I firmly believe in
the enormous benifit of the free exchange of code and information.  The
Scores virus is a very interesting and complicated piece of code, I've
learned a great deal about the Mac by studying it, and I'm sure other
people could learn a great deal from it too.  But I don't want to teach
twisted minds how to write these incredibly nasty bits of code.  If I
write the disinfectant program, however, I will distribute its source,
because I do want to teach untwisted minds how to get rid of them.

So please don't bombard me with requests for more information.  You may
be the nicest, most honest, incredibly important person, but I won't
tell you how it works.  I'll make only two exceptions, and that's for a
very few of my colleagues at Northwestern University, and for qualified
representatives of Apple Computer.

Thanks to Howard Upchurch for giving us a copy of the virus, and to Bob
Hablutzel for helping me crack it.
--
John Norstad
Northwestern University
Academic Computing and Network Services
2129 Sheridan Road
Evanston, IL 60208

Bitnet:   JLN@NUACC
Internet: [e-mail]

Monday morning, April 18, 1988.


------------------------------

From: [e-mail] (J.Grant)
Subject: Calling all Lisa owners/users ...
Date: 18 Apr 88 11:23:44 GMT
Organization: UNIKENT Plc., UK

I thought that it might be a nice idea if Lisa/MacXL users got in
contact with each other.

Despite companies like Sun & Dafax, these machines do not have much of a
following (c. 30,000) and yet they are still perfectly usable.

Perhaps with this message I may get the ball rolling ?

Come on all you Lisa/XL users ... speak up !


------------------------------

From: [e-mail] (Hans Mulder)
Subject: info on expert-system shells sought
Date: 18 Apr 88 19:32:09 GMT
Organization: Delft University of Technology, Netherlands

I need information on "expert-system shells" (or whatever you want to
call them) for the Macintosh. I am specifically interested in
information on the AI concepts and user-interface facilities available.

Any information or pointers appreciated.
--
Hans Mulder
mcvax!dutesta!hansm


------------------------------

From: [e-mail] (Jan Harrington)
Subject: AUX book
Date: 19 Apr 88 18:23:34 GMT
Organization: Scholastech, Inc., Waltham, Mass.

I've been talking with a publisher about writing a book on AUX.  The
intent of the book (currently estimated to be about 600 pages in length)
would be to hit the highlights of what you have to know to get started
with Apple's implementation of Unix. I'm tentatively planning to cover
the most frequently used Unix commands (including telecommunications),
shell programming, C programming, and the interface to the Mac Toolbox
(though I don't intend to teach programming itself).

Would such a book be of interest to anyone out there? Would you turn to
such a book before talking the two shelves of documentation that come
with AUX?

What in particular would you find useful in a book designed to make AUX
more accessible?

Any comments would be gratefully accepted.
--
Jan Harrington, sysop
Scholastech Telecommunications
UUCP: ihnp4!husc6!amcad!stech!sysop or allegra!stech!sysop
BITNET: JHARRY@BENTLEY

********************************************************************************
    Miscellaneous profundity:

        "No matter where you go, there you are."
                Buckaroo Banzai
********************************************************************************


------------------------------

From: [e-mail] (Irvin Lustig)
Subject: Landscape printing
Date: 18 Apr 88 14:29:02 GMT
Organization: Princeton University, NJ

I am writing an application that must do all printouts in landscape
mode, no matter which printer is attached.  When the user selects "Page
Setup", I want the application to default to landscape printing. I would
like to do this ***without testing the type of printer connected***. I
did the following:
   Take the Print Record created by choosing Landscape in Page Setup
when
   an Imagewriter is chosen, and save the contents in a resource.  Then
   pass a handle that resource to PrValidate and use the modified
result. This has the desired result for when an ImageWriter is selected,
but when I pass the ImageWriter resource when the LaserWriter is chosen,
PrValidate changes the resource to the default for the LaserWriter and
doesn't realize that Landscape was chosen for the ImageWriter.

So what I really want is for the Landscape option chosen for one printer
to "carry over" to the other printer (and any others that might be out
there).  The only option seems to be saving a PrintRecord resource for
an ImageWriter and a LaserWriter and passing the appropriate resource to
PrValidate.  My concern is if some other printer with a different driver
comes along, then I have to create the proper resource for that printer.

Any suggestions?

     -Irv Lustig
     Asst. Professor
     Department of Civil Engineering and Operations Research
     Princeton University
     Send e-mail to:  [e-mail]



------------------------------

From: [e-mail] (Thomas Fruin)
Subject: MultiFinder switch bug with custom WDEFs
Date: 19 Apr 88 03:04:40 GMT
Organization: uvabick

MultiFinder won't let you switch when there is a modal dialog box open
on the screen, since the user is expecting a modal situation.  To
determine this, MultiFinder looks to see (among other things) if the
window definition procedure of that window is dBoxProc.  (I'm quoting
Technical Note 180 here)

Unfortunately MultiFinder doesn't look good enough.  It _only_ examines
the window's variation code, assuming that you are using the standard
WDEF with resource ID 0.  I have written my own WDEF that mimics Apple's
standard WDEF for document windows, but let's you have funky patterns in
the title bar (among other things).  I have my own variation codes that
behave similar to, but not completely the same as Apple's variation
codes.  And you guessed it: I also use a variation code of 1 (dBoxProc
== 1).  I assumed MultiFinder would at least check the resource ID of
the WDEF it is examining - my WDEF has a resource ID of 128, which would
give the particular window that is        giving me problems a window
definition ID of 2049 (16 * 128 + 1).

Sadly, MultiFinder ignores the resource ID completely.  So if anybody
out there is using custom WDEFs, make sure to avoid variation code 1.
It was a weird experience not being able to switch at all, even though I
had document windows on top.

I hope Apple fixes this oversight.

-- Thomas Fruin

   [e-mail]                       University of Leiden
   [e-mail]                        University of Amsterdam
   [e-mail]
   hol0066.AppleLink
   2:508/15.FidoNet                           The Netherlands


------------------------------

From: [e-mail] (Frederick Wamsley)
Subject: Re: I fixed an unreadable floppy...now you can too !
Date: 20 Apr 88 05:34:36 GMT
Organization: Whole Earth 'Lectronic Link, Sausalito, CA

In article <[e-mail]> [e-mail] writes:
>Ever had a disk go 'unreadable' on you ? Well, read on...
>
[Helpful description of using low-level utilities to revive a disk]

Before you start a project like this, use Copy II or some other
copy-anything-that's-there utility to duplicate the damaged disk. Your
first experiment might fail and leave you worse off, so it's important
to have a duplicate on which you can start over.
--
Fred Wamsley  {dual,hplabs}!well!alcmist;well![e-mail];
CIS 72247,3130; GEnie FKWAMSLEY;ATT Mail fwamsley; USPS - why bother?
"I was just being polite, sir"  -  Lt. Worf


------------------------------

From: [e-mail]
Subject: banner programs?
Date: 19 Apr 88 20:41:00 GMT


Has anyone seen any PD/SW programs that can easily produce banners on
the Mac imagewriter?  By banners I mean long signs with letters from 5
to 8 inches tall printed horizontally down the continuous-feed paper in
one long line. Do any existing commercial programs do this (superpaint,
word, whatever)? Seems like a fairly simple thing to do.  I'm not picky
about the font, just want something that will do the job quickly
(preferably by reading a file so we don't have to type in all 76
messages again).

Thanks in advance for any tips - please reply by email to:

        David McNabb

        Department of Computer Science
        University of Illinois at Urbana-Champaign
        USENET:    ...!{cmcl2,seismo,ihnp4}!uiucdcs!mcnabb
        ARPA:    [e-mail]


------------------------------

From: [e-mail] (Malcolm M Dickinson)
Subject: Re: banner programs?
Date: 20 Apr 88 15:57:03 GMT
Organization: Yale University, New Haven, CT

Yes.  There is a program that I got from the Yale Macintosh Users' Group
that does just that.  It is called MacBillboard 4.01 and is available
either from your local users' group under the "MacHonor" system, or for
$35 from

    CE Software
    801 - 73rd St.
    Des Moines, IA  50312

Malcolm


------------------------------

From: [e-mail] (Christopher Brian Cox)
Subject: PICT2 - bitmap compression
Date: 20 Apr 88 03:09:27 GMT
Organization: Carnegie Mellon University

I need some help:

        I would like to find out exactly what compression scheme Apple
is using in the PICT2 bitmap format.  I assumed that it would be the
same PackBits as the older monochrome PICT.  When I tried using PackBits
to compress the bitmap the machine crashed while reading the bitmap.
Inside Mac V is definately wrong in it's description of the compression,
in addition to other facts about the PICT2 format.
        Does anyone know what compression scheme they are using?  Could
you please send me some information about it?

        The reason I'm asking is:  I am trying to convert images off of
a larger computer system to PICT2 format.  I want to (almost have to) do
all of the conversion work on the larger system, so I can't use
QuickDraw.

Thank you very much,
--
Chris Cox
[e-mail]


------------------------------

From: [e-mail] (Norbert Lindenberg)
Subject: Bug in MPW 2.0.2 Link tool
Date: 19 Apr 88 18:12:03 GMT
Organization: University of Karlsruhe, W.-Germany

One bug seems to have been fixed in the MPW 2.0.2 Link tool, but I
discovered yet another one.

The bug occurs if you declare an object type in the implementation part
of a unit and define a new method for this type (new as opposed to
overriding a superclass method), and let the linker optimize method
calls (-opt option). The new method does not show up in the method table
listing produced with the -p option, and the linker still produces a
%_SelProcs segment. According to MacApp DA newsletter 1/5, this segment
should never be present in an optimized program. When I start the
program, it drops into MacsBug with a User break: Method not found
message when the new method is called.

Any comments, Larry or Jordan?

-- Norbert


------------------------------

From: [e-mail] (George Pavel)
Subject: Cursor only moves vertically.  Why?
Date: 20 Apr 88 19:32:04 GMT
Organization: Lawrence Livermore Labs, Livermore Ca

Recently I experienced a crash on my Mac Plus with System 4.1 and Finder
5.3. After rebooting, the cursor would only respond to vertical
movements of the mouse ( not a very useful situation).  Thinking that I
had somehow munged my System, I took the opportunity to upgrade to
System 4.2 and Finder 6.0.  The same thing happened.  I replaced the
Finder and the Mouse cdev with fresh copies and it seemed to cure it,
but a later reboot showed that the problem reoccurred. Further
experimentation shows that this vertical-only mode happens on most
reboots but not all; if I try long enough, I get full cursor control.
Moving the mouse around while the Mac is rebooting may or may not help;
it's hard to tell.  I haven't tried eliminating INITs yet to see if one
of them might be causing it.  When this first occurred, I hadn't made
any changes to the system for about a month.  Does anyone have any idea
where I can look for the problem?

(I have a lot of stuff in the System Folder: SoundInit, A ScrapSaver,
BeepInit, Boot Logger, CheapBeep, CPS TagFix, CPSSaveDeletes, Autoblack,
Macsbug, Findswell, JClock31patched (which has never caused me any
problems, yet), mind, New Rom Sys Alert, Randomizer, SCSI Bus CDEV,
SFScrollInit, ShutDownSoundInit, Softtalk, Suitcase, Tops, PopKeys.  As
I said before, all this was unchanged for at least a month, during which
I had to reboot several times without a problem.)
--
George Pavel
Lawrence Livermore National Laboratory
P.O. Box 808  L-68                (was [e-mail])
Livermore, CA 94550            Internet: [e-mail]
[phone]                UUCP: ihnp4!lll-lcc!gp


------------------------------

From: [e-mail] (Steve Masticola)
Subject: Re: Cursor only moves vertically.  Why?
Date: 20 Apr 88 21:57:38 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

Have you checked the hardware? (connections tight, no sticky encoder
wheels, no open wires, etc.) You could test the Mac with someone else's
mouse if you can borrow one.

Even if all that's OK, it could still be a hardware problem (i.e.,
encoder counter or something like that) inside the Mac. Not having
access to any Mac hardware manuals (doubtless any that exist would be
published without Apple's permission), I can't tell you specifically
where to look. My guess is it's going to be either one of the custom
chips or a PAL (with the READ fuse thoughtfully blown by Apple, of
course :-( .

If the problem persists, try your software on another Mac. It's really
unlikely to be a software problem if it's specific to one machine
(although in the case of the fellow who removed his batteries to
initialize default settings, it seems it can happen.)

- Steve.


------------------------------

From: [e-mail] (Jeff Meyer)
Subject: DataDesk Mac-101 Keyboard for the Mac Plus (non-ADB) and startup
Date: 20 Apr 88 21:30:44 GMT

Just ordered one of the Datadesk Mac-101 extended keyboards for the Mac
Plus.  However, there's one thing I noticed about the Mac-101 that
Datadesk confirmed when I called them: the keyboard isn't enabled until
the system file is loaded (at least on the non-ADB model).  Thus,
hitting the shift key so that Font/DA Juggler won't load, or the Cmd key
so that the machine comes up in Finder Mode when startup is set to
MultiFinder mode, doesn't work.

My question: a)  anyone know if there is a workaround on this?  b)
Anyone know if Datadesk will/can fix this bug?

Thanks....

                          "According to my instruments -- they're
preparing
                           to jump into hyper-space... or go to warp
                           drive... or something like that."
--
                                        Moriarty, aka Jeff Meyer
INTERNET:     [e-mail]
Manual UUCP:  {uw-beaver, sun, microsoft}!fluke!moriarty
CREDO:        You gotta be Cruel to be Kind...
<*> DISCLAIMER: Do what you want with me, but leave my employers alone! <*>


------------------------------

From: [e-mail] (Michael Homsey)
Subject: Kspool/hiding 'LaserWriter'
Date: 20 Apr 88 00:20:49 GMT
Organization: OTC Development Unit, Australia

I am seeking assistance re hiding the laserwriter on our appletalk
network. Let me explain, we us a LW as output device for ditroff as well
as a printer on the appletalk network. To access the LW from both
sources we have a kinetics fastpath and K-spool from kinetics. A
'LaserWriter' really a daemon appears on the appletalk network to which
people can 'choose', it caches information that the printer normally
supplies to an application (ie what fonts do you have etc - it talks
pap)

Now to the point, how can the name of the LaserWriter (ie the real
printer) be hidden from mac users - allowing them to access it via the
unix spooler via k-spool) remember the printer still has to be accessed
from the Unix machine. (a pyramid 9810 running mainly Sys V).

please respond via email.
--
      Michael Homsey               [e-mail]
      OTC, Systems Development     {uunet,mcvax}!otc.oz!msh
      Box 7000 Sydney NSW 2001     Voice: [phone]
      Australia                    Fax:   [phone]


------------------------------

From: [e-mail] (Marc T. Kaufman)
Subject: Re: DataDesk Mac-101 Keyboard for the Mac Plus (non-ADB) and startup
Date: 21 Apr 88 01:36:24 GMT
Organization: Stanford University

I looked at the Mac-101 Keyboard for possible A/UX use.  Forget it.  It
has only one (1) 'control' key, and that one placed akwardly on the
right.


------------------------------

From: [e-mail] (Chuq Von Rospach)
Subject: Re: DataDesk Mac-101 Keyboard for the Mac Plus (non-ADB) and startup
Date: 21 Apr 88 04:10:50 GMT
Organization: Fictional Reality

All you need to do is wait until the smiling mac comes up and hitting
the shift key works fine. At least it does on mine.


Chuq Von Rospach            [e-mail]        Delphi: CHUQ

                                                Welcome to the Latrine
Wall!
                               What do you want to do, number 1 or
number 2?


------------------------------

From: [e-mail] (Jim Kateley)
Subject: Re: Mac II ROM upgrade
Date: 21 Apr 88 23:36:26 GMT
Organization: Apple Computer Inc, Cupertino, CA

The MacII logic board upgrade does two (and only two) things:

It fixes a ROM bug so you can can have more than 1MB of address space on
a NuBus card.

It changes a HAL that caused a slight timing problem between NuBus cards
that can become bus master.

You would need this upgrade if:

You have a NuBus card that needs more than 1MB of address space You have
NuBus card(s) that can become bus master.

You do NOT need this upgrade if:

You are running A/UX (If you don't believe me, I have two machines doing
it, and I don't know how to tell them the bad news.... :-)) You are
using an Apple Video card or Ethertalk interface card  (neither of them
can become bus master).

The only NuBus card I know of (to date) that needs this upgrade  is the
National Semiconductor RAM board.

This board will NOT

Make your disk access twice as fast.

--
Jim Kateley          UUCP: {sun, voder, nsc, mtxinu, dual}!apple!kateley
S,P,HnS!             DOMAIN: [e-mail]  Applelink: kateley1
Disclaimer:   What I say, think, or smell does not reflect any policy or
          stray thought by Apple Computer, Inc.


------------------------------

From: [e-mail] (Phil Goldman)
Subject: Re: MultiFinder switch bug with custom WDEFs
Date: 20 Apr 88 18:03:43 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]> [e-mail] (Thomas Fruin) writes:
>MultiFinder won't let you switch when there is a modal dialog box open
>on the screen, since the user is expecting a modal situation.  To determine
>this, MultiFinder looks to see (among other things) if the window definition
>procedure of that window is dBoxProc.  (I'm quoting Technical Note 180 here)
>...
>Sadly, MultiFinder ignores the resource ID completely.  So if anybody out
>there is using custom WDEFs, make sure to avoid variation code 1.  It was
>a weird experience not being able to switch at all, even though I had
>document windows on top.


This is not a bug, but merely an oversight in not documenting the
conditions completely.  dBoxProc is reserved for modal dialogs, no
matter what the WDEF is.  This is necessary because we have to allow for
the system (or even an app) to easily patch the standard WDEF by adding
some code to the front and then falling thru to the standard on
e.  This
would cause problems if we checked the resource ID too.

The reason that all of this checking is necessary in the first place is
because some applications will put up a modal dialog without actually
calling the trap _ModalDialog to handle it.  If it always was called we
probably would not have looked at the var code at all.

-Phil Goldman Apple Computer

------------------------------

End of Usenet Mac Digest
************************
-------
-------